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DETAILED ACTION 
Claim Rejections - 35 USC § 101 

1. 35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of 
matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the 
conditions and requirements of this title. 

Claim 1-3, 5, 7-9, 26-29, 31 and 40 are rejected under 35 U.S.C. 101 because 
the claimed invention is directed to non-statutory subject matter. 

Regarding claims 26 and 40, they are written in a form of "computer program 
product". Firstly, such limitation is required to be rewritten as "a computer-readable 
medium storing instructions", plus the additionally claimed computer readable signals 
are non-statutory and should be removed, as per the 101 Interim Guide, p. 52. 

When claims 26 and 40 fall within one of the statutory categories, we continue to 
ask the following question: Does the claimed invention cover a judicial exception? The 
answer is "Yes", i.e. an abstract idea-computer program. 

Once the claim covers a judicial exception, we need to determine whether the 
claim recites (1) a physical transformation and (2) provides a useful, concrete and 
tangible result as a practical application. Thus, claim 26 are non-statutory because the 
patent protection sought by the claimed invention is for the computer program, an 
abstract, where independent claims 26 and 40 lack descriptive language in which the 
transformation steps yield a useful, concrete and tangible result. 

Regarding claims 1-3, 5, 7-9, 27-29 and 31 they are written in a form of 
"method". However, as evidenced in claims 26 and 40, independent claims 1 and 27 
are claiming computer/software instructions in the form of a method. Note that claims 1 
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and 27 closely mirror claims 26 and 40 respectively in almost all respects except for the 
preamble, and in light of the specification they are nothing more than the instructions of 
the application. Thus, similar to independent claims 26 and 40, independent claims 1 
and 27 also lack descriptive language in which the transformation steps yield a useful, 
concrete and tangible result . 

Claim Rejections - 35 USC § 103 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 1 02 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

2. Claims 1-3, 5 and 26 are rejected under 35 U.S.C. 103(a) as being unpatentable 

over See (US 2003/0021283) in view of Curie (US 6,871,232). 

Regarding claim 1, See describes a system of controlling usage of network 

resources on a communication network, comprising: 

(a) creating one or more packet rules (policy rules) for analyzing packets 
received at one or more devices of the communications network, each rule including a 
condition and action to be taken if a packet received at a device satisfies the condition 
(fig. 4 and paragraph 35); 

(b) storing the one or more packet rules (paragraph 35, policy rules stored in 
repository table); 
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(c) creating one or more service abstractions (policy groups), each service 
abstraction representing a [named] set of one or more of the packet rules (paragraph 
35, "According to one embodiment, the policy rules are organized into policy groups 
based on a rule type 52"; 

(d) storing the one or more service abstractions (paragraph 35, policy groups 
stored in repository table); 

(e) associating one or more of the service abstractions with a computer host of 
the communications network (paragraph 27, where network devices may be computer 
hosts, and paragraph 30, "According to one embodiment, the policies relevant to a 
particular network device 24, 26, 28 are selected based on a role assigned to the 
device" and paragraph 35, "A rule type may organize policies into role policies"). 

See fails to describe: 

controlling usage based on the identity of an authenticated user, and associating 
one or more service abstraction with an authenticated user. 
Curie describes: 

controlling usage based on the identity of an authenticated user, and associating 
one or more service abstraction with an authenticated user (abstract, fig. 1 1 A, col. 1 1 , 
lines 50-52 & col. 17, lines 16-18, user authentication, plus col. 21, lines 50-65, 
associating/grouping common policy (abstraction) with the user). 

It would have been obvious to one with ordinary skill in the art at the time of 
invention by applicant to describe an authenticated user is used for controlling network 
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usage and is associated with an service abstraction as described in Curie for the 
network usage control of See. 

The motivation for combining the teachings is that it enables the resource 
provisioning of plurality of organizations (with different users) using a single, centralized 
logical server (Curie, col. 3, lines 41-57). 

Regarding claim 2, See describes all limitations set forth in claim 1. See further 
describes: 

(f) configuring a network device of the communications network with one or more 
packet rules according to at least one of the service abstractions (policy groups) 
(paragraph 26, "The policy repository 22 stores^a plurality of policy rules that may be 
used by the network devices 24, 26, 28 to control different network elements" and 
paragraph 38, "The action 58 may be identifying a policy group based on a device 
attribute..") 

Regarding claim 3, See describes all limitations set forth in claim 2. See further 
describes: 

configuring a port module of a switching device of the communications network 
with one or more packet rules according to at least one of the service abstractions 
(paragraph 22, "According to one embodiment, the network policies are used to 
disable network ports based on predetermined conditions,") 

Regarding claim 5, See describes all limitations set forth in claim 1. See further 
describes: 
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(C) distributing the one or more service abstractions to one or more network 
devices residing on the communications network (paragraph 30, "According to one 
embodiment, the policies relevant to a particular network device 24, 26, 28 are selected 
based on a role assigned to the device" and paragraph 35, "A rule type may organize 
policies into role policies"). 

Regarding claim 26, See describes a system of controlling usage of network 
resources on a communication network, comprising: 

(a) creating one or more packet rules (policy rules) for analyzing packets 
received at one or more devices of the communications network, each rule including a 
condition and action to be taken if a packet received at a device satisfies the condition 
(fig. 4 and paragraph 35); 

(b) storing the one or more packet rules (paragraph 35, policy rules stored in 
repository table); 

(c) creating one or more service abstractions (policy groups), each service 
abstraction representing a named set of one or more of the packet rules (paragraph 35, 
"According to one embodiment, the policy rules are organized into policy groups based 
on a rule type 52". 

(d) storing the one or more service abstractions (paragraph 35, policy groups 
stored in repository table); 

See lacks describing that a computer program product to perform the above- 
mention process, comprising: 
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a computer readable medium and computer readable signals stored on the 
computer readable medium that define instructions that, as a result of being executed 
by a computer, instruct the computer to perform the process. 

The examiner takes official notice that the system of See may be implemented 
using a computer comprising a readable medium and a program with instructions which 
executes the process. The motivation being that such implementation using a [generic] 
computer may be more economical and faster to develop than via a customized 
hardware system. 

See fails to describe: 

controlling usage based on the identity of an authenticated user, and associating 
one or more service abstraction with an authenticated user. 
Curie describes: 

controlling usage based on the identity of an authenticated user, and associating 
one or more service abstraction with an authenticated user (abstract, fig. 1 1 A, col. 1 1 , 
lines 50-52 & col. 17, lines 16-18, user authentication, plus col. 21, lines 50-65, 
associating/grouping common policy (abstraction) with the user). 

It would have been obvious to one with ordinary skill in the art at the time of 
invention by applicant to describe an authenticated user is used for controlling network 
usage and is associated with an service abstraction as described in Curie for the 
network usage control of See. 
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The motivation for combining the teachings is that it enables the resource 
provisioning of plurality of organizations (with different users) using a single, centralized 
logical server (Curie, col. 3, lines 41-57). 

3. Claim 7-9, and 11, 27-29 and 31 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over See in view of Azarmi (5,905,715), and further in view of Curie, 

Regarding claim 7, See and Curie describe all limitations set forth in claim 1, 
where the user is an authenticated user (Curie, col. 17, lines 16-18). 

See and Curie combined lack what Azarmi describes: 

(f) creating one or more role abstractions (feature-describing data set), each role 
abstraction representing a role of a user with respect to the communications network 
(manageable aspect of the communications network), and each role abstraction 
including a set of one more service abstractions (management rule profiles) (col. 2, lines 
42-51, & fig. 20 where such control/provisioning is for [associated with] individual users). 

It would have been obvious to one with ordinary skill in the art at the time of 
invention by applicant to specify (another) role abstraction layer to group the (existing) 
service abstraction layer. The motivation being that "It defines a structural architecture 
within which business processes, and therefore management systems required to 
provide services on a network", Azarmi, col. 2, lines 10-12). 

Regarding claim 8, See, Curie and Azarmi combined describe all limitations set 
forth in claim 7. See, Curie and Azarmi further describe: 
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(g) configuring a network device of the communications network with one or more 
packet rules according to one of the role abstractions (See, paragraph 26, "The policy 
repository 22 stores a plurality of policy rules that may be used by the network devices 
24, 26, 28 to control different network elements" and See, paragraph 38, "The action 58 
may be identifying a policy group based on a device attribute.." where the policy group 
[i.e. sen/ice abstraction layer] is replaced by Azarmi's feature set [i.e. role abstraction 
layer]). 

Regarding claim 9, See, Curie and Azarmi combined describe all limitations set 
forth in claim 8. See, Curie and Azarmi further describe: 

configuring a port module of a switching device of the communications network 
with one or more packet rules according to at least one of the role abstractions (See, 
paragraph 22, "According to one embodiment, the network policies are used to 
disable network ports based on predetermined conditions", where the policy (group) [i.e. 
sen/ice abstraction layer] is replaced by Azarmi's feature set [i.e. role abstraction layer]). 

Regarding claim 11, See, Curie and Azarmi combined describe all limitations 
set forth in claim 7. See, Curie and Azarmi further describe: 

(g) distributing the one or more role abstractions to one or more network devices 
residing on the communications network (See, paragraph 30, "According to one 
embodiment, the policies relevant to a particular network device 24, 26, 28 are selected 
based on a role assigned to the device" and See, paragraph 35, "A rule type may 
organize policies into role policies", where the role (policy) [i.e. service abstraction layer] 
is replaced by Azarmi's feature set [i.e. role abstraction layer]). 
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Regarding claims 27, See describes a method of controlling usage of network 
resources on a communication network, comprising: 

(a) defining one or more packet rules (policy rules) for analyzing packets 
received at one or more devices of the communication network, each rule including a 
condition and action to be taken if a packet received at a device satisfies the condition 
(fig. 4 and paragraph 35); 

(b) providing the one or more packet rules (paragraph 35, packet rules in 
repository table ready for use); 

See lacks what Azarmi describes: 

(c) defining one or more role abstractions (feature-describing data set), each role 
abstraction representing a role of a user with respect to the communications network 
(manageable aspect of the communications network), and each role abstraction 
including a set of one more packet rule (management rule profiles containing 
management rules) (col. 2, lines 42-51, & fig. 20 where such control/provisioning is for 
[associated with] individual users). 

(d) providing the one or more role abstractions (col. 2, lines 30-34, provided for 
monitoring and controlling the service provisions). 

It would have been obvious to one with ordinary skill in the art at the time of 
invention by applicant to specify the role abstraction layer to group the packet rules 
(layer). The motivation being that "It defines a structural architecture within which 
business processes, and therefore management systems required to provide services 
on a network", Azarmi, col. 2, lines 10-12. 
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See and Azarmi combined fails to describe: 

controlling usage based on the identity of an authenticated user, and associating 
one or more service abstraction with an authenticated user. 
Curie describes: 

controlling usage based on the identity of an authenticated user, and associating 
one or more service abstraction with an authenticated user (abstract, fig. 1 1 A, col. 1 1 , 
lines 50-52 & col. 17, lines 16-18, user authentication, plus col. 21, lines 50-65, 
associating/grouping common policy (abstraction) with the user). 

It would have been obvious to one with ordinary skill in the art at the time of 
invention by applicant to describe an authenticated user is used for controlling network 
usage and is associated with an service abstraction as described in Curie for the 
network usage control of See and Azarmi. 

The motivation for combining the teachings is that it enables the resource 
provisioning of plurality of organizations (with different users) using a single, centralized 
logical server (Curie, col. 3, lines 41-57). 

Regarding claim 28, See and Azarmi combined describes all limitations set forth 
in claim 27. See and Azarmi further describe: 

(e) configuring a network device of the communications network with one or more 
packet rules according to one of the role abstractions (See, paragraph 26, "The policy 
repository 22 stores a plurality of policy rules that may be used by the network devices 
24, 26, 28 to control different network elements" and See, paragraph 38, "The action 58 
may be identifying a policy group based on a device attribute.." where the policy group 
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[i.e. service abstraction layer] is replaced by Azarmi' s feature set [i.e. role abstraction 
layer]). 

Regarding claim 29, See and Azarmi combined describe all limitations set forth 
in claim 28. See and Azarmi further describe step (C) of: 

configuring a port module of a switching device of the communications network 
with one or more packet rules according to at least one of the role abstractions (See, 
paragraph 22, "According to one embodiment, the network policies are used to .. 
disable network ports based on predetermined conditions", where the policy (group) [i.e. 
service abstraction layer] is replaced by Azarmi's feature set [i.e. role abstraction layer]). 

Regarding claim 31, See and Azarmi combined describe all limitations set forth 
in claim 27. See and Azarmi further describe step (C) of: 

(e) distributing the one or more role abstractions to one or more network devices 
residing on the communications network (See, paragraph 30, "According to one 
embodiment, the policies relevant to a particular network device 24, 26, 28 are selected 
based on a role assigned to the device" and See, paragraph 35, "A rule type may 
organize policies into role policies", where the role (policy) [i.e. service abstraction layer] 
is replaced by Azarmi's feature set [i.e. role abstraction layer]). 

4. Claims 13-15 and 17 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over See in view of Nessett and Curie. 

Regarding claim 13, See describes a system for controlling usage of network 
resources on a communications network, the system comprising: 
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creating one or more packet rules for analyzing packets received at one or more 
devices of the communications network, each rule including a condition and action to be 
taken if a packet received at a device satisfies the condition; and 

creating one or more service abstractions, each service abstraction representing 
a named set of one or more of the packet rules. 

[assigning logic to] associate one or more of the service abstractions with a user 
(computer host) of the communications network (paragraph 27, where network devices 
may be computer hosts, which is a user of the communication network, and paragraph 
30, "According to one embodiment, the policies relevant to a particular network device 
24, 26, 28 are selected based on a role assigned to the device" and paragraph 35, "A 
rule type may organize policies into role policies"). 

storage means for storing one or more packet rules (paragraph 35, policy rules 
stored in repository table); 

See lacks what Nessett describes: 

a rule editing module [to create pack rules] (fig. 1, security policy management 
back-end #32) and a service editing module [means to create service abstractions] (fig. 
1 , security policy language interpreter #34) 

It would have been obvious to one with ordinary skill in the art at the time of 
invention by applicant to specify respective editing modules to be used for creating the 
packet rules and service abstractions as specified in See. The motivation for using 
separate modules in performing layered rules & service abstraction functionality is "As 
the partitioning becomes finer grained, access to resources outside of the firewall 
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partition experiences increasing degraded performance. Another approach to this 
problem is to distribute firewall functionality down into lower layers of the protocol 
hierarchy" (Nessett, col. 2, lines 51-56). 

See and Nessett combined fail to describe: 

controlling usage based on the identity of an authenticated user, and associating 
one or more service abstraction with an authenticated user. 
Curie describes: 

controlling usage based on the identity of an authenticated user, and associating one or 
more service abstraction with an authenticated user (abstract, fig. 11 A, col. 11, lines 50- 
52 & col. 17, lines 16-18, user authentication, plus col. 21, lines 50-65, 
associating/grouping common policy (abstraction) with the user). 

It would have been obvious to one with ordinary skill in the art at the time of 
invention by applicant to describe an authenticated user is used for controlling network 
usage and is associated with an service abstraction as described in Curie for the 
network usage control of See and Nessett. 

The motivation for combining the teachings is that it enables the resource 
provisioning of plurality of organizations (with different users) using a single, centralized 
logical server (Curie, col. 3, lines 41-57). 

Regarding claim 14, See, Nessett and Curie combined describe all limitations 
set forth in claim 13. See further describes: 

. [logic to] configure a network device of the communications network with one or 
more packet rules according to at least one of the service abstractions (policy groups) 
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(paragraph 26, "The policy repository 22 stores a plurality of policy rules that may be 
used by the network devices 24, 26, 28 to control different network elements" and 
paragraph 38, "The action 58 may be identifying a policy group based on a device 
attribute..") 

Regarding claim 15, See, Nessett and Curie combined describe all limitations 
set forth in claim 14. See further describes: 

[port configuration logic] to configure a port module of a switching device with 
one or more packet rules according to at least one of the service abstractions 
(paragraph 22, "According to one embodiment, the network policies are used to .. 
disable network ports based on predetermined conditions,") 

Regarding claim 17, See, Nessett and Curie combined describe all limitations 
set forth in claim 1 3. See further describes: 

a distribution module (fig. 2, policy repository #20) to distribute the one or more 
service abstractions to one or more network devices residing on the communications 
network (paragraph 30, "According to one embodiment, the policies relevant to a 
particular network device 24, 26, 28 are selected based on a role assigned to the 
device" and paragraph 35, "A rule type may organize policies into role policies"). 

5. Claims 19-21 and 23 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over See in view of Nessett and Curie, and further in view of Azarmi. 
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Regarding claim 19, See, Nessett and Curie combined describe all limitations 
set forth in claim 13, where the user is an authenticated user (Curie, col. 17, lines 16- 
18). 

See, Nessett and Curie combined lack what Azarmi describes: 

A role editing module (Nessett, fig. 1 , front end #31) to create one or more role 
abstractions (feature-describing data set), each role abstraction representing a role of a 
user with respect to the communications network (manageable aspect of the 
communications network), and each role abstraction including a set of one more service 
abstractions (management rule profiles) (col. 2, lines 42-51). 

It would have been obvious to one with ordinary skill in the art at the time of 
invention by applicant to specify (another) role abstraction layer to group the (existing) 
service abstraction layer. The motivation being that "It defines a structural architecture 
within which business processes, and therefore management systems required to 
provide services on a network", Azarmi, col. 2, lines 10-12. 

Regarding claim 20, See, Nessett, Curie and Azarmi combined describe all 
limitations set forth in claim 19. See, Nessett, Curie and Azarmi further describe: 

[logic to] configure a network device with one or more packet rules according to 
one of the role abstractions (See, paragraph 26, "The policy repository 22 stores a 
plurality of policy rules that may be used by the network devices 24, 26, 28 to control 
different network elements" and See, paragraph 38, "The action 58 may be identifying a 
policy group based on a device attribute.." where the policy group [i.e. service 
abstraction layer] is replaced by Azarmi's feature set [i.e. role abstraction layer]). 
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Regarding claim 21, See, Nessett, Curie and Azarmi combined describe all 
limitations set forth in claim 20. See, Nessett, Curie and Azarmi further describe: 

[port configuration logic to] configure a port module of a switching device with 
one or more packet rules according to one of the role abstractions (See, paragraph 22, 
"According to one embodiment, the network policies are used to .. disable network ports 
based on predetermined conditions", where the policy (group) [i.e. service abstraction 
layer] is replaced by Azarmi 's feature set [i.e. role abstraction layer]). 

Regarding claim 23, See, Nessett, Curie and Azarmi combined describe all 
limitations set forth in claim 19. See, Nessett and Azarmi further describe: 

a distribution module (See, fig. 2, policy repository #20) to distribute the one or 
more role abstractions to one or more network devices residing on the communications 
network (See, paragraph 30, "According to one embodiment, the policies relevant to a 
particular network device 24, 26, 28 are selected based on a role assigned to the 
device" and See, paragraph 35, "A rule type may organize policies into role policies", 
where the role (policy) [i.e. sen/ice abstraction layer] is replaced by Azarmi 's feature set 
[i.e. role abstraction layer]). 

6. Claims 33-35, 37 and 40 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over See in view of Azarmi, Nessett and Curie. 

Regarding claims 33 and 40, See describes a system of controlling usage of 
network resources on a communication network [official notice taken that the system 
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may be implemented using a computer comprising a readable medium and a program 
with instructions which executes the process], comprising: 

creating one or more packet rules (policy rules) for analyzing packets received at 
one or more devices of the communication network, each rule including a condition and 
action to be taken if a packet received at a device satisfies the condition (fig. 4 and 
paragraph 35); 

storage means for storing one or more created packet rules (paragraph 53, 
repository table storing the policy (packet) rules); 
See lacks what Azarmi describes: 

creating one or more role abstractions (feature-describing data set), each role 
abstraction representing a role of a user with respect to the communications network 
(manageable aspect of the communications network), and each role abstraction 
including a set of one more packet rule (management rule profiles containing 
management rules) (col. 2, lines 42-51 , & fig. 20 where such control/provisioning is for . 
[associated with] individual users). 

It would have been obvious to one with ordinary skill in the art at the time of 
invention by applicant to specify the role abstraction layer to group the packet rules 
(layer). The motivation being that "It defines a structural architecture within which 
business processes, and therefore management systems required to provide services 
on a network", Azarmi, col. 2, lines 10-12. 

See and Azarmi combined lack what Nessett describes: 
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a rule editing module [to create pack rules] (fig. 1, security policy management 
back-end #32) and a role editing module (Nessett, fig. 1 , front end #31) [means to 
create role abstractions]. 

It would have been obvious to one with ordinary skill in the art at the time of 
invention by applicant to specify respective editing modules to be used for creating the 
packet rules and service abstractions as specified in See and Azarmi. The motivation 
for using separate modules in performing layered rules & service abstraction 
functionality is "As the partitioning becomes finer grained, access to resources outside 
of the firewall partition experiences increasing degraded performance. Another 
approach to this problem is to distribute firewall functionality down into lower layers of 
the protocol hierarchy" (Nessett, col. 2, lines 51-56). 

See, Azarmi and Nessett combined fails to describe: 

controlling usage based on the identity of an authenticated user, and associating 
one or more service abstraction with an authenticated user. 
Curie describes: 

controlling usage based on the identity of an authenticated user, and associating 
one or more service abstraction with an authenticated user (abstract, fig. 1 1 A, col. 1 1 , 
lines 50-52 & col. 17, lines 16-18, user authentication, plus col. 21, lines 50-65, 
associating/grouping common policy (abstraction) with the user). 

It would have been obvious to one with ordinary skill in the art at the time of 
invention by applicant to describe an authenticated user is used for controlling network 
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usage and is associated with an service abstraction as described in Curie for the 
network usage control of See, Azarmi and Nessett. 

The motivation for combining the teachings is that it enables the resource 
provisioning of plurality of organizations (with different users) using a single, centralized 
logical server (Curie, col. 3, lines 41-57). 

Regarding claim 34, See, Nessett and Azarmi combined describe all limitations 
set forth in claim 33. See, Nessett and Azarmi further describe: 

[logic to] configure a network device of the communications network with one or 
more packet rules according to one of the role abstractions (See, paragraph 26, "The 
policy repository 22 stores a plurality of policy rules that may be used by the network 
devices 24, 26, 28 to control different network elements" and See, paragraph 38, "The 
action 58 may be identifying a policy group based on a device attribute.." where the 
policy group [i.e. service abstraction layer] is replaced by Azarmi's feature set [i.e. role 
abstraction layer]). 

Regarding claim 35, See, Nessett and Azarmi combined describe all limitations 
set forth in claim 34. See, Nessett and Azarmi further describe step (C) of: 

[port configuration logic] to configure a port module of a switching device of the 
communications network with one or more packet rules according to at least one of the 
role abstractions (See, paragraph 22, "According to one embodiment, the network 
policies are used to .. disable network ports based on predetermined conditions", where 
the policy (group) [i.e. service abstraction layer] is replaced by Azarmi's feature set [i.e. 
role abstraction layer]). 
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Regarding claim 37, See, Nessett and Azarmi combined describe all limitations 
set forth in claim 33. See, Nessett and Azarmi further describe step (C) of: 

a distribution module (See, fig. 2, #20) to distribute one or more role abstractions 
to one or more network devices residing on the communications network (See, 
paragraph 30, "According to one embodiment, the policies relevant to a particular 
network device 24, 26, 28 are selected based on a role assigned to the device" and 
See, paragraph 35, "A rule type may organize policies into role policies", where the role 
(policy) [i.e. service abstraction layer] is replaced by Azarmi' s feature set [i.e. role 
abstraction layer]). 

Response to Arguments 

7. Applicant's arguments with respect to claims 1-3, 5, 7-9, 11, 13-15, 17, 19-21, 23, 
26-29, 31 , 33-35, 37 and 40 have been considered but are moot in view of the new 
ground(s) of rejection. 

Conclusion 

8. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Warner Wong whose telephone number is 571-272- 
8197. The examiner can normally be reached on 6:30AM - 3:00PM, M-F. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Wing Chan can be reached on 571-272-7493. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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